While updating the
TeX Live package for Debian for the upcoming 2015 release, one of my aims was to convert as much as possible of the TeX configuration infrastructure to use
dpkg triggers. We used the trigger mechanism already for the update of the font map configuration file (calls to updmap-sys), but till now neither for files installed into texmf trees, nor for format generation. In this blog I will describe the new management of all TeX related configuration files, while in the following one I will describe how things have been implemented with dpkg triggers. In due time this information will also be codified in the Debian TeX sub-policy.
Let us start with recalling the different actions that have to be taken when TeX packages are installed, removed, or updated.
Required actions for TeX packages
Filename database
The simplest case are packages that only include files ment to be loaded while running TeX or Metafont or similar programs. In this case the file name database of TeX (and the one of ConTeXt) needs to be updated. Usually this is done by calling
mktexlsr on the changed trees, plus, if ConTeXt is installed, running
mtxrun --generate.
Font map activation
More complicated are font packages that provide PostScript fonts. These packages need to ship a so called
map file which maps TeX font names to PostScript fonts names. Examples are
lm.map which defines this mapping for the Latin Modern fonts. All these map files have to be collected in one or more
updmap.cfg files, and then a call to
updmap(-sys) is necessary to generate configuration files for
dvips,
pdftex, and some other programs.
Format and hyphenation definitions
Even more complicated is the case of additional hyphenation patterns and additional format definitions. At the moment, hyphenation patterns are
only shipped from the TeX Live packages itself, but additional format definitions are already provided by other packages than the TeX Live ones. Again, in both cases all the different format and hyphenation pattern definitions must be combined, into configuration files
fmtutil.cnf and several
language.* files, respectively. After this some incantation of
fmtutil(-sys) is necessary to update the format dumps of TeX.
Status up to Debian/TeX Live 2014
Up to now most of these actions are done in the postinstall script of the providing packages, generated by
dh_installtex. The
tex-common package shipped besides the program
dh_installtex also postinstall and postrm snippets that took care of all the necessary steps, and ensuring that configuration succeeds even if some of the programs were missing.
While this worked quite nicely for many years, I saw several disadvantages:
- The postinstall script of many packages got bloated with a lot of complicated code. While this is not bad by itself, it is bad when a bug is found in this generated code because it requires a rebuild of all packages using dh_installtex.
- As before, fixes or improvements in tex-common are not picked up automatically, due to separate code.
- Package authors might forget to call dh_installtex and only install the files, which would result in unusable (for TeX) files.
Furthermore,
/etc/texmf/ was filled with snippet-configuration directories, e.g.,
/etc/texmf/hyphen.d/ and
/etc/texmf/fmt.d/ where the standard configuration of TeX was saved, and system administrators could change the necessary settings.
While this is a good thing, i.e., to give system administrators the chance to change their configuration, it carries a big risk: most system administrators, most users, have not the blankest idea how to write a proper format definition for TeX, nor a proper entry for a hyphenation pattern. And the TeX engines are not forgiving in this respect and will bail out immediately.
Finally, having so many configuration files hanging around in
/etc/texmf/ makes it complicated to update between releases, where these files might have changed completely, files might have been added or removed.
New layout for Debian/TeX Live 2015 and onward
Thanks to a
rewrite of fmtutil in Perl (also one of my endeavors), and adding the capability to read multiple
fmtutil.cnf files in the same way
updmap can read multiple
updmap.cfg files, starting with Debian/TeX Live 2015 we can finally do the following:
- switch to completely trigger based activation;
- moving all format and hyphen related configuration files out of /etc/texmf/.
So let us dive into the details, following the above order:
Filename database
Update of the filename databases is now done automatically via a trigger on the two directories that are searched by kpathsea and used by Debian packages:
/usr/share/texlive/texmf-dist/ (for TeX Live packages) and
/usr/share/texmf/ (for all other packages).
Thus, if a Debian package installs files into one of these directories, automatically
mktexlsr (and, if ConTeXt is installed also
mtxrun) is run from the
tex-common trigger action.
As a consequence for package maintainers of TeX related packages, if you are not adding font maps, formats, or hyphens, there is no need anymore to call
dh_installtex or do anything TeX specific besides installing the files into the proper locations.
Font map activation
Here nothing has changed from the previous status, I just repeat that map snippets should be installed into
/var/lib/tex-common/fontmap-cfg/texlive/ (for TeX Live packages) and
/var/lib/tex-common/fontmap-cfg/texmf/ (for all other packages).
One snippet can contain arbitrary many
Map or
MixedMap lines. Example:
/var/lib/tex-common/fontmap-cfg/texmf/tex-gyre.cfg:
Map qag.map
Map qbk.map
Map qcr.map
Map qcs.map
Map qhv.map
Map qpl.map
Map qtm.map
Map qzc.map |
There is a necessary action to be taken in
postinst and
postrm, which is calling
update-texmf-conf map (but take care when writing your own code in postrm, as
update-texmf-conf might not be available!).
Format and hyphenation definitions
Format definitions and hyphenations are now treated in the very same way as font maps. That is:
- Format and hyphenation definitions need to be installed into the relevant sub-directories of /var/lib/tex-common/fmtutil-cnf/ and /var/lib/tex-common/hyphen-cnf, respectively. Relevant sub-directories here refers to either texlive (for TeX Live packages) or texmf (for all other packages), similar to the font map case.
- Maintainer scripts need to call update-texmf-conf format and update-texmf-conf hyphen, respectively.
Package maintainers are advised to use
dh_installtex as it also caters for the removal of format dumps under
/var/lib/texmf/web2c.
Format of the configuration files
Files under
/var/lib/tex-common/fmtutil-cnf/ must consist of syntactically correct lines for
fmtutil.cnf, that is white-space separated entries where the first word is the name of the format, the second the name of the engine, the third the respective hyphenation configuration file or a literal if none, and the rest of the line are additional arguments to the respective
initex program, where the last entry is the ini-file. A typical example would be
/var/lib/tex-common/fmtutil-cnf/texlive/texlive-omega.cnf:
aleph aleph - *aleph.ini
lamed aleph language.dat *lambda.ini |
Files under
/var/lib/tex-common/hyphen-cnf have a slightly changed syntax from the ones we used to have back in
/etc/texmf/hyphen.d. The new syntax is taken directly from the TeX Live database, execute statement AddHyphen. That is one line of
key=value pairs, where the following keys are allowed:
name,
synonyms,
lefthyphenmin,
righthyphenmin,
file,
file_patterns,
file_exceptions, and
luaspecial. A typical example would be
/var/lib/tex-common/hyphen-cnf/texlive/texlive-lang-polish.cnf:
name=polish lefthyphenmin=2 righthyphenmin=2 file=loadhyph-pl.tex file_patterns=hyph-pl.pat.txt file_exceptions=hyph-pl.hyp.txt |
In addition, package maintainers that have shipped files in
/etc/texmf/fmt.d or
/etc/texmf/hyphen.d are advised to remove them on package upgrade, using
PACKAGE.maintscript and the proper
rm_conffile directive (see the
musixtex package for an example.
Overriding system settings
In case an administrator wants to override any of the default setting, it has become much easier in case of font maps and formats, due to the multi-feature of the respective programs. For hyphenations a separate configuration file needs to be provided.
Overriding font maps and formats
This can be handled by dropping a
updmap.cfg or
fmtutil.cnf file, respectively, into either
/etc/texmf/web2c/ or
/usr/local/share/texmf/web2c/ (both will work). The new files will be evaluated by the respective programs (
updmap(-sys) and
fmtutil(-sys), respectively), and allow by default to override entries in other files. Please see the manual page of the two programs for details, or
this entry for updmap and
this entry for fmtutil.
Overriding hyphenation patterns
When generating the various
language.* files,
update-language evaluates
last the file
/etc/texmf/web2c/local-hyphen.cnf, which should contain hyphenation patterns in the very same format as described above. Using this entry one can add additional patterns, or override given ones.
Current status of uploads
Several packages have already been uploaded to experimental:
tex-common,
musixtex,
context,
texinfo. What remains are the TeX Live packages itself, but here we are facing two problems:
texlive-bin has been in NEW queue for over a month, and now has been rejected due to new complains on the since years unchanged copyright file. Well, I had already a new version in the upload queue, which extends the copyright file. So I had to build a new -1 version and re-upload it to the NEW queue. Let us see whether this one will go through. (now accepted and in experimental!)- There is an un-overridable lintian error which will create an auto-reject when uploading my packages. This lintian error is bogus, as reported both to the lintian maintainers and to ftp-masters. Unfortunately no reaction from ftp-masters for now, so I don t waste anyones time uploading the packages for now.
So, in case you cannot wait for the next century to happen (or, that all the packages are accepted), and still want to give it a shot, here are the apt-get lines:
deb http://people.debian.org/~preining/TeX/ exp/
deb-src http://people.debian.org/~preining/TeX/ exp/ |
but be warned, there might be more changes coming in.
Warnings: First, in case you have already texlive-binaries 2015.20150524.37493-2 installed, please downgrade to the
new version -1 which is now on the server. They are the same packages, only the version number has changed. Yes, and if you test it, don t be surprised if suddenly you are left with a not-working TeX system. Don t tell me I didn t warn you
Anyway, I hope to hear some feedback and installation reports.
Conclusion
While packaging has become easier for maintainers, and there is less clutter in
/etc/texmf/, we now are depending on
dpkg to call the
tex-common triggers. Thus, if this happens rather often, then especially
fmtutil-sys --all will be called several times. This is a slight regression from the previous setup, but paid off (IMNSHO) by the arguments given in the beginning.
That said, there will be of course a certain time of transition until the new setup has proven its merits, and bugs are ironed out. But having bugs that need to be mostly fixed only in one package, namely
tex-common, seems like an easier task to me.
Enjoy.
PocketCHIP is the pocket sized
Linux terminal I always used to want. Which is to say, it runs (nearly)
stock Debian, X, etc, it has a physical keyboard, and the hardware and
software is (nearly) non-proprietary and very hackable. Best of all, it's
fun and it encourages playful learning.
It's also clunky and flawed and constructed out of cheap components.
This keeps it from being something I'd actually carry around in my pocket
and use regularly. The smart thing they've done though is embrace these
limitations, targeting it at the hobbiest, and not trying to compete with
smart phones. The PocketCHIP is its own little device in its own little
niche.
Unless you're into hardware hacking and want to hook wires up to the GPIO
pins, the best hardware feature is the complete keyboard, with even
Escape and Control and arrow keys. You can ssh around and run vi on it,
run your favorite REPL (I use ghci) to do quick programming, etc.
The keyboard is small and a little strange, but you get used
to it quickly; your QWERTY muscle memory is transferrable to it.
I had fun installing nethack on it and handing it to my sister who
had never played nethack before, to watch her learn to play.
The screen resolution is 480x272, which is pretty tiny. And, it's a cheap
resistive touchscreen, with a bezil around it. This makes it very hard to
use scroll bars and icons near the edge of the screen. The customized
interface that ships with it avoids these problems, and so I've been using
that for now. When I have time, I plan to put a fullscreen window
manager on it, and write a pdmenu menu configuration for it, so
everything can be driven using the keyboard.
I also have not installed Debian from scratch on it yet. This would be
tricky because it uses a somewhat patched kernel (to support the display
and wifi). The shipped distribution is sadly not entirely free software.
There are some nonfree drivers and firmwares. And, they included a non-free
gaming environment on it (a very nice one for part of the audience, that
allows editing the games, but non-free nevertheless). They did do a good
job of packaging up all the custom software they include on it, although
they don't seem to have
published source packages for everything.
(They might be infringing my GPL copyright of flash-kernel by distributing
a modified version without source. I say "might" because flash-kernel is
a pile of shell scripts, so you could probably extract the (probably
trivial) modifications. Still.. Also, they seem to have patched
network-manager in some way and I wasn't able to find the corresponding source.)
The battery life is around 5 hours. Unfortunately the "sleep" mode only
turns off the backlight and maybe wifi, and leaves the rest of the system
running. This and the slightly awkward form factor too big to really
comfortably fit in a pocket limit the use of PocketCHIP quite a bit.
Perhaps the sleeping will get sorted out, and perhaps I'll delete the GPIO
breakout board from the top of mine to make it more pocket sized.
For jfontmaps the changes were minimal, 
What happened in the 
When it all worked fine almost
In June, I bought a new laptop, and a new SSD for it. I used that model
of SSD before (Samsung 840 Evo), although not for a long time, so I
wasn't expecting anything unusual.
Since the laptop is a slower one, I installed Debian as follows:
connect SSD to my workstation, do an install on it (via Virtualbox
connected to the raw device), disconnect and install in the
laptop. First sign of trouble was that the SSD didn't boot reliably. I
said - maybe my Virtualbox method (new method) wasn't right - so I
reinstalled on the laptop, and everything was mostly OK.
Mostly OK because rarely the laptop had issues with seeing the
SSD. Maybe not cold booting, requiring a restart, or giving some ATA
errors on boot (bot nothing afterwards). I didn't use the laptop too
much - I mostly use it when travelling - so I didn't investigate
further.
Trouble begins
Fast forward to two weeks ago: I was preparing to leave on a trip, so
I booted the laptop (everything OK), 
The GUI is written using the PyQT Toolkit and the options in the GUI are generated at runtime, based on the list of available power saving modules.
Apart from the GUI configuration tool, this release also includes some bug fixes:
I just received a 
The story: I tend to do proactive replacement of hard drive, to avoid losing too much data or be in hurry when the current one fails. There are two ways to monitor a hard drive:
I apologize for inadvertently password protecting 
So, sometime over the past few weeks I clocked up ten years as a
Debian developer:
My friend